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has reserves. The conduct of the project is, in essence, the 
management of the depletion of those reserves, so that every 
available resource is used to the maximum extent possible. 

— Al Diaz, from his ASK interview (p. 30) 
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Welcome to the Academy of Program and Project 
Leadership (APPL) and ASK Magazine. APPL helps 
NASA managers and project teams accomplish today's 
missions and meet tomorrow’s challenges by providing 
performance enhancement services and tools, supporting 
career development programs, sponsoring knowledge 
sharing events and publications, and creating opportu- 
nities for project management collaboration with univer- 
sities, professional associations, industry partners, and 
other government agencies. 

ASK Magazine grew out of APPL's Knowledge 
Sharing Initiative. The stories that appear in ASK are 
written by the "best of the best" project managers, 
primarily from NASA, but also from other government 
agencies and industry. These stories contain knowledge 
and wisdom that are transferable across projects. Who 
better than a project manager to help another project 
manager address a critical issue on a project? Big projects, 
small projects — they're all here in ASK. 

Please direct all inquiries about ASK Magazine editorial 
policy to EduTech Ltd., 8455 Colesville Road, Suite 930, 
Silver Spring, MD 20910, (301) 585-1030; or email to 
editors@edutechltd.com. 
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in this issue Denise Lee 


ASK Magazine Experiences Change 


The AP PL Knowledge Sharing Initiative with its many tangible benefits and ASK 
as its premier product, is now recognized across NASA, the Federal Government, 
and the Private Sector as an example of innovation in government 


The first issue of ASK Magazine was released in 
January 2001, the brainchild of Dr. Edward Hoffman 
and Dr. Alexander Laufer. I came to work on this project 
in May of 2001 , and at that time the Knowledge Sharing 
Initiative at APPL was a ‘start up’. As with any 'start up’ 
the hope within the new team was that we would be 
successful, but the question loomed large: What did 
success look like? Dr. Edward Hoffman, the APPL 
Director, wrote in the first issue of ASK, “ASK will 
provide a format that is easy, accessible and open. The 
stories and columns that appear in this bi-monthly 
magazine will offer simple yet powerful advice, lessons, 
insights, humor and narratives that underscore what 
makes NASA projects so meaningful — the competence 
and passion of the people who work on them." 

We have come a long way since then. Success has 
been glimpsed on many occasions. This success, as 
Dr. Hoffman pointed out, can be attributed to the 
competence and the passion of our team, and of course 
all of the wonderful storytellers over the years. The 
Knowledge Sharing team, through their hard work and 
dedication, elevated ASK from a ‘start up’ to the award- 
winning publication that it is today. I would like to 
express the sentiments of the entire APPL team by 
commending the work that Todd Post and, more 
recently, Jody Brady did in contributing to taking this 
publication from obscurity to become a premier project 
management publication. The APPL Knowledge 
Sharing Initiative with its many tangible benefits and 
ASK as its premier product, is now recognized across 


NASA, the Federal Government, and the Private Sector 
as an example of innovation in government. Todd had 
been with ASK from the beginning and was instrumental 
in crafting and shaping the magazine. As with any 
innovative initiative, there were times when Todd had to 
fight and scratch to gain ground and achieve the next 
level of success. It was Todd’s unwavering dedication for 
which we always remember him. The team and I wish 
them all the best as Todd and Jody move on to pursue 
new opportunities. 

In the next issue of ASK Magazine we will be intro- 
ducing you to the new Editor, who will be working with 
the Editor in Chief, Dr. Alexander Laufer, to launch ASK 
to the next level of success. Until then, I will be Acting 
Editor and can be contacted for any questions or 
requests that you need addressed. 

Your comments, as always, are appreciated on the 
interviews, stories and columns shared in this issue of 
ASK Magazine. • 
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REVIEW BOARD 


JOHN BRUNSON of the Marshall Space Flight Center is a 
member of the NASA Program Management 
Council Working Group. He served as project 
manager for three separate microgravity 
payloads that flew on various Spacelab 
missions. His career in the space industry' began 
in 1980 as a technician working on the first Space Shuttle. 

DR. MICHELLE COLLINS works in the Spaceport Engineering & 
Technology Research Group at Kennedy Space 
Center. She has over 20 years experience in 
aerospace spanning engineering, R&D, and 
project management. She is on the the Horida 
Institute of Technology Dept, of ChE Industrial 
Advisory Board, the National Fire Protection Association's Technical 
Committee for Halon Alternatives, and the United Nations 
Environmental Programme Halon Technical Options Committee. 

HECTOR DELGADO is Di\ 'ision Chief of Process Tools and 
Techniques in the Safety, Health and 
K . Independent Assessment Directorate at the 
Kennedy Space Center. In 1995, he served as 
Senior Technical Staff to the NASA Chief 
H Engineer at NASA Headquarters in Washington, 
D.C. He has received many honors and awards including the 
Exceptional Service Medal, Silver Snoopy Award, and various 
achievement awards. 

DR. OWEN GADEKEN is a Professor of Engineering Management 
at the Defense Acquisition University where he 
has taught Department of Defense program 
and project managers for over twenty' years. He 
retired last year from the Air Force Reserve as a 
Colonel and Senior Reservist at the Air Force 
Office of Scientific Research. He is a frequent speaker at project 
management conferences and symposia. 

HECHT has been with NASA since 1982 at the 
Jet Propulsion Laboratorv (JPL). He is instru- 
ment manager and lead investigator for the 
MECA soil-analysis payload on the 2007 
Phoenix mission to Mars, reprising a role he 
played on the cancelled 2001 Mars Surveyor 
Lander mission. In the course of his JPL career his has served 
in line, program, and project management, and has participated 
in research ranging from fundamental semiconductor physics 
to martian geophysics. 

JODY ZALL KUSEK is a Senior Evaluation Officer at the World 
Bank. She is currently involved in supporting 
the efforts of seven governments to move to a 
focus of performance-based management. She 
has spent many years in the area of public 
sector reform, serving the Vice President of the 
United States, the U.S. Secretary of the Interior, and the U.S. 
Secretary of Energy in the areas of Strategic Planning and 
Performance Management. 



DR. MICHAEL 






DONALD MARGOLIES retired from the Goddard Space Flight 
Center in January 2004. He was Project Manager 
for the Advanced Composition Explorer (ACE) 
mission, launched in 1997 and still operating 
successfully. He received the NASA Medal for 
Outstanding Leadership for his work on ACE, 
and a NASA Exceptional Service Medal for the Active 
Magnetospheric Particle Tracer Explorers (AMPTE) mission. 



DR. GERALD MULENBURG is the Manager of the Aeronautics 
and Spaceflight Hardware Development 
Division at the NASA Ames Research Center. 
He has project management experience in 
airborne, spaceflight, and ground research 
projects with the Air Force, industry, and NASA, 
as Executive Director of the California Math 
Science Task Force and as Assistant Director of the Lawrence 
Hall of Science. 



He also served 


JOAN SALUTE is the Associate Director for projects in the 
Information Sciences and Technology Directorate 
at Ames Research Center. She has managed many 
NASA projects including those involving flight 
testing of thennal protection materials, commer- 
cial technology, commercial applications of 
remote sensing, and remote sensing science projects. She has been 
at Ames for twenty years, and was awarded the Sloan Fellowship to 
attend Stanford Graduate School of Business. 



HARVEY SCHABES is currently assigned to the Systems 
Management Office at the Glenn Research 
Center. He started his career with NASA in 
icing research, and since then has served in 
numerous organizations in support of the 
Space Station Program. 




CHARLIE STEGEMOELLER is Manager of the Johnson Space 
Center (JSC) Human Space Life Sciences 
Programs Office. He is responsible for the 
programmatic and tactical implementation of 
the lead center assignments for Space Medicine, 
Biomedical Research and Countermeasures, 
and Advanced Human Support Technology. He began his 
career at NASA in 1985 with JSC Comptroller's Office as a 
technical program analyst. 

HUGH WOODWARD is the President of Macquarie Business 
■HLJH Concepts, a consulting firm specializing in 
effective project portfolio management. Before 
this position, he had a 25-year career with 
Procter & Gamble. He served as the Chairman 
of the Project Management Institute (PMI) for 
consecutive terms in 2000 and 2001 . He was elected to the Board 
of Directors in 1996, and before being elected as the Chair, served 
as vice chair and in several other key leadership roles. 
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from the director’s desk Dr. Edward Hoffman 


High-Performance Projects and 
the "Culture Thing" 


The research is in and what it tells us, repeatedly, is that good project cultures 
lead to high performance and satisfaction, bad ones to failure and turnover 


Culture [is] a pattern of basic assumptions — invented , discovered, or developed by a given group 
as it learns to cope with its problems of external adaptation and internal integration — 
that has worked well enough to be considered valid and, therefore, to be taught to new members 
as the correct way to perceive, think, and feel in relation to those problems. 

— Edgar H. Schein, Organizational Culture and Leadership 


The obvious question, then, for every project leader 
is: What can you do to establish a culture of high 
performance and value? 

The starting point is to realize that the project leader 
has the greatest impact on a project team’s culture. 
Forget about everything else and every other excuse. 
Successful project leaders find ways to design cultures of 
high performance — cultures where quality and innova- 
tion exists side by side and where intrinsic motivation 
and personal satisfaction go hand-in-hand. 

Leadership shapes the communication, behavior, 
rituals, stories, values, and day-to-day performance on a 
project. It's the attitude of the leader that engenders the 
support of the team members. Projects which provide 
meaningful work, autonomy, and performance feedback 
stand out as the optimal cultures. 

But what can you do to cultivate a high-perform- 
ance culture? It doesn’t have to be as glib as, “You either 
got it, kid, or you don’t." 

In support of NASA project teams, the Academy of 
Program and Project Leadership (APPL) has sponsored 
research that has generated a simple yet powerful organ- 
izing system for project leadership and culture. Through 
APPL’s Performance Enhancement services, this system 
provides project leaders the competencies to understand. 


predict, and shape performance culture by focusing on four 
dimensions: Directing/Organizing, Visioning/Inventing, 
Valuing/Honoring, and Relating/Including. 

Projects are assessed to formulate improvement 
strategies, which may include APPL mentoring and 
coaching services from some of the best project leaders 
in the world. Some project managers choose to have 
their teams participate in a three-day workshop designed 
to help understand and improve project culture. 
Assessments are repeated after about three months, and 
results thus far reveal a statistically significant improve- 
ment in project culture. 

The success of NASA comes down to the successful 
performance of our programs and projects. The project 
world is one of complexity, uncertainty, and ever- 
changing variables. High-performance culture is 
essential for success — and you, as the project leader, are 
the greatest influence on your team’s culture. If you want 
it, APPL has support available for you and your project 
team. Let me know how I can help. 

Dr. Hoffman can be reached at ehoffman@nasa.gov. * 
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Getting to Jupiter would be no easy matter, even in the best of conditions — so when we 
set our schedule, we aimed at having our Galileo spacecraft ready in time to take 
advantage of a window of opportunity in early 1982, when celestial conditions would 
favor our mission. We were assigned a berth on the 25th Shuttle mission, scheduled for 
February of '82 — the first time the Shuttle would be used for a planetary mission. 


The trouble was that the Shuttle was still under 
development when that schedule was set. As time went 
on, the Shuttle had problems with its high pressure 
turbines, thermal protection tiles, engines, and more. 
The early launch dates had to be scrapped. NASA 
Headquarters told us, "We're going to delay your 
launch two years to allow more time for the Shuttle 
development to take place. You can slow your develop- 
ment accordingly.” 

Right off the bat, we looked into the celestial 
mechanics and how they would affect us. The difficulty 
in launching a spacecraft to Jupiter changes on a year-to- 
year basis, in a cyclical pattern that repeats about every 
ten or twelve years. In order to achieve the velocity 
needed to get from low earth orbit to Jupiter, an upper 
stage is required in the Shuttle. For the 1982 launch the 
upper stage was adequate, but it could not provide the 
velocity we would need in 1 984. This meant we would 
have to separate the Galileo probe from the Galileo orbiter 
before launch and put each of them on separate Shuttles 
with separate upper stages. 

When we told the folks at Headquarters this, they 
told us, "Okay we'll give you two Shuttle launches.” 


WE ADJUST OUR PLANS 

Separating the probe from the orbiter wasn't the real 
challenge. We needed to do that as the spacecraft 
approached Jupiter, anyway. What we needed was a probe 
carrier, a spacecraft to service the probe on the way to 
Jupiter. This required an entirely new development. We 
could do that, if necessary, but 1 worried that we couldn't 
get the design completed in time and within our budget. 
When I told them this at Headquarters, they said, "Well, 
maybe you ought to cancel this mission." I told them that 
we would find a way. 

We got every one lined up and working on the new 
development for more than a year — when someone said, 
“If the Centaur [an upper stage used on the Titan] could 
be adapted for use on the Shuttle, then we could put 
these two spacecraft back together." The Centaur upper 
stage uses liquid hydrogen and liquid oxygen, which is 
much more powerful than the Inertial Upper Stage (IUS) 
that we were going to use. So, we started working that 
idea through. Some people didn’t think it would work, 
some thought it would take too long, and we all worried 
about the cost of the thing — but we kept working the 
problem as we explored all our options. 
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Preparing the spacecraft Galileo for flight. 

we had the capability to go into orbit around Jupiter and 
stay there for several years and do multiple flybys, close 
flybys — the equivalent of ten or more Voyager missions. 
There was the opportunity cost again, you see? You 
could do with this one spacecraft what it would have 
taken ten, or even twenty Voyagers. 

I spoke to people on Capitol Hill to relay this 
message. The project manager doesn't do that anymore; 
Headquarters does. But even at the time, I got to do 
things not usually done because a lot of people had 
written our project off. The people on the Hill listened. 
In the end, they supported us, and gave us the money to 
keep going. 


Finallv, in early 1986 we were set to launch a large 
liquid oxygen/liquid hydrogen upper stage in a rocket 
inside the Shuttle with our spacecraft on top of it. We 
put everything together, and brought our spacecraft to 
Kennedy Space Center for the launch. Then came the 
Challenger accident. The Shuttle was grounded. 

On top of that, upper management came back to us 
and said that we had to be more conservative when we got 
back to flight. "We’ve decided that the Centaur upper 
stage is too risky; you can't use it. You can use the IUS,” 
they told me. But it was the same story as in 1 984: The old 
one wouldn't get us there unless we split Galileo apart. 


By this time we already had the spacecraft built — so 
splitting it apart was out of the question. Those were the 
darkest days for me on this project, but 1 never gave up hope. 

SELLING THE PROJECT 

I knew my team would eventually find a way to get 
Galileo launched, and I knew what the spacecraft could 
deliver — but it wasn't an easy sell. When I went in front 
of senior NASA management, I made an opportunity 
cost argument to them. I pointed out that for the 
increment of funding we still needed, they could, in 
essence, buy an entire mission. The sunk cost didn't 
count because they couldn’t recover that — it was water 
under the bridge. So, what was the opportunity cost of 
that additional increment that we would need to finish? 
Could they buy something of more value for that same 
amount of money? 

We were in the middle of the Cold War then, so I 
also used the argument that what we were doing would 
make a powerful statement to the Soviets. “We’re going 
to go to Jupiter, 500 million miles away, and we can 
deliver the spacecraft with an accuracy of plus or minus 
fifteen miles. That speaks volumes of our capabilities.” I 
also told them that we would get data back at higher 
rates than previously thought possible. In all, we could 
demonstrate an enormous engineering capability to the 
rest of the world in a non-threatening way. For if we 
could send something like this to Jupiter, think of what 
we could do on Earth. 

1 described how compelling the mission was in 
terms of the science return we could expect. I reminded 
them that we knew without a doubt that that our target 
was rich because Voyager had told us that. We knew that 
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AND WE REGROUP 

Galileo was built; we just needed to find a way to get it to 
Jupiter. I engaged everyone in the project to think this 
thing through. I asked them, "What are other ways to 
approach this launch?" 

First, we looked at using a Russian launch vehicle 
that might be capable of launching our spacecraft. 
Though relationships with Russia still weren't all that 
great at that point, we talked to them and found out 
what it would take. They were willing to discuss the idea 
further with us, but we decided it was too marginal. We 
took a look at doing enhancements to other launch 
vehicles, but saw that wouldn't work, either. 



People tried to tell me again that this mission was 
never going to happen. I never accepted that. 1 just kept 
my team going. People said to me, "Okay that's it." 1 just 
shook my head. They said, “How do you know that's not 
it? You haven't found a solution.” All I told them was, 
"Well, we haven't concluded that there isn’t a solution.” 

In order to design our original mission we had 
developed the mathematics and trajectory design tools 
to do multiple flybys of Jupiter's moons. So when we 
found ourselves without a launch vehicle, we decided to 
put that technology to use and see if we could apply it to 
solving the problem of getting to Jupiter. My people 
sketched out all sorts of approaches to the problem. 
Nothing was working. 

Still, I kept them focused on the excitement of the 
science we hoped to return, and kept them working on 
the problem. My message to them was, "This is a good 
mission. Keep your eye on the ball. Don't look down. 
Look up. Together, we'll find a way out of this.” 1 had to 
keep doing that not only with our people here, but with 
Congress and with the people at Headquarters. 


Then — I’ll never forget the day — I was sitting in my 
office one morning when an engineer walked into my 
office. He said, “You probably won't go for this, but 1 
think I found a way to get to Jupiter.” 

He went up to the white board and sketched out a 
trajectory. He said, "Here is what we can do. Instead of 
going out this way to Jupiter, we'll start off going to 
Venus. We’ll do a gravity assist at Venus to add a bit of 
velocity. We'll come back to the Earth and pick up more 
velocity. We’ll go out past the asteroids and then we'll 
come back to the Earth a second time and then back to 
the asteroid belt. It will take four years, but we’ll be ready 
to go to Jupiter." 

I looked at this guy for a moment, thinking about 
the implications. Before I could say anything he said, 
“Well, I didn’t think you would like it.” 

“Are you kidding?" I asked. “I love it. Let’s do it.” 

He said he was worried about the changes we would 
need to make the spacecraft capable of handling the 
increased thermal environment near Venus and of 
handling the new telecommunication geometry that 
would be required. “We'll take care of that part,” I said. 
“You just go figure out this trajectory.” He and a couple 
of other guys went off and did a more complete analysis 
and design. 

We would add about four years to the flight with the 
time spent around Venus and the two passes by Earth. 
Instead of getting to Jupiter in the two years and nine 
months we had planned on, it would take about six 
years. We had used trajectories before to gain velocity on 
space missions, but we had never attempted a “triple” 
like this one. It would mean trading trip time for launch 
energy, and that had clear disadvantages. But it looked as 
though we would only have to make moderate adjust- 
ments to our spacecraft design. 

That was good enough for me. We would use the 
trajectory to get to Jupiter. 

I beard, 11 Jou havtHf -found 
a. saluHon.MII I said was, 
i * well, we haven't concluded 
that -there isWf a saluHin ." 
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A NEW PHASE 

I had been on the project for ten years, three months, 
and two days, when my boss was promoted and they 
offered me his job overseeing all the flight projects at the 
Jet Propulsion Laboratory. It was hard to leave the 
project at that point, but I did get to stay involved and 
see it launched in 1989 — even though I was no longer 
the project manager. 

I watched with pride as our mission flew the trajec- 
tory, delivering valuable science data for Venus, the 
Earth and moon, and the asteroid belt. Finally, Galileo 
headed for its rendezvous with Jupiter and its moons — 
and arrived in December 1995. Its eight years and 35 
orbits around Jupiter turned out to be everything we 
hoped it would be. Tenacity certainly has its rewards. 

We put Galileo to sleep last year. A lot of people were 
sorry to see it go. You know, I didn't think of it that way. 
It was out of fuel, and there was nothing much more we 
could do with it. It was going to die one way or another. 
We decided to send it on a collision course with Jupiter, 
sending us back data from the planet’s magnetic field as 
it went. We threw a farewell party on Galileo's last day 
and we celebrated its success. 


Those mere 1 he darkest days 
tbr vne on 'Wife project but 
\ never gave up tope* 

Galileo gave us more science than we could have 
hoped for. T.S. Eliot once speculated that the world 
would end "not with a bang but a whimper." Well, we 
decided that Galileo deserved to go out with a bang. • 

Lessons 

• A project team takes its lead from the project manager. 
When managers make clear their own commitment to 
and belief in their projects, they empower their teams to 
overcome problems that crop up. 

• An important part of any project manager’s job is 
to "sell" a project — not just to get the project off the 
ground but to keep the project alive when surmountable 
obstacles arise. That “selling" may require creative 
thinking to frame the project in a way that makes its 
value more apparent to project sponsors. 

Question 

Under what circumstances might a project manager decide that 
a project should no longer be "sold"? 


Originally called the Jupiter Orbiter Probe, 
the Galileo mission described in this story 
V found evidence that Jupiter's icy moons 

(Europa, Ganymede, and Callisto) appear 
to have the necessary ingredients for life: water, energy 
and the right chemical content. 

So, who better to kick off a return mission to study the 
moons than Galileo project manager JOHN CASANI? 
Currently, Casani heads up work to develop the Jupiter 
Icy Moons Orbiter (JIMO) project, an ambitious proposed 
mission that would return an orbiter to the Jovian system 
some eight years after launch in 201 1 or later. 


Casani began working at the Jet Propulsion Laboratory in 
1956. In the 1960s he was spacecraft design leader and 
system manager for the Mariner spacecraft that flew to 
Venus, Mars, and Mercury. He went on to serve as project 
manager on the Voyager, Galileo, and Cassini missions, 
and as JPL's first Chief Engineer, among other positions. 
Honors for his work include NASA's Distinguished 
Service, Outstanding Leadership, and Exceptional 
Achievement medals. 

Following his 1999 retirement, Casani served on several 
JPL review and advisory boards, including heading up 
the Mars Polar Lander failure investigation board. But 
retirement didn't stick. Casani returned to the JPL project 
management ranks in 2000. 
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BY FR ANK sn0W 


E verything looked good as we started the first day of vibration tests on the High Energy Solar Spectrascopic Imager 
(HESSI). We chose to do our environmental testing at the Jet Propulsion Laboratory (JPL) in California and, so, we had 
brought our spacecraft there from Spectrum Astro in Arizona. 

We planned to launch in July 2000. Heading into March that year we were on schedule, under budget, meeting all of our 
performance requirements, and ready for the final testing. I remember feeling proud of what the development team, lead by 
the University of California at Berkeley and its project manager, Peter Harvey, had accomplished in the last two-and-a-haif 
years. We were in the homestretch— or so I thought. 


Near the end of the day, it was time for the sign 
burst test. For 200 milliseconds we would put a non- 
feedback force on our system, which meant we couldn't 
adjust or halt the test in process. Something went 
wrong, terribly wrong during the sign burst test. As 
mission manager, 1 was standing just ten feet away from 
the spacecraft when this happened. It sounded like a 
dap of thunder. With the test stopped, we moved in 
closer to see what had happened— and we knew 
immediately that we had damaged our spacecraft. How 
much, we didn't know. 

• 
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Once they got our spacecraft off the table, it was 
fairly obvious what had caused the problem: One of the 
support bearings on the vibration test bed had failed. 
This caused an abnormally high level of static friction, 
which the computer read as mass. When it tried to 
compensate by increasing vibration, it shook the space- 
craft ten times harder than we had planned. 

If anyone knows Tom Gavin, Director of Flight 
Projects at JPL, they know that he likes to share a little 
piece, of information with engineers during reviews: "If 

you have an anomaly, you're going to meet a lot of 

' ' : : 




important people." Well, 1 started meeting a lot of 
important people as soon as word spread about our 
testing disaster. 

Three days later, I stood in front of the Mishap 
Board to open the investigation. The Mishap Board 
concluded that two primary factors contributed to the 
accident: the absence of a scheduled maintenance 
program for the test equipment, and the lack of proper 
test procedures. 

I don't think that I was alone in thinking about 
Mishap Boards with trepidation. But I learned a lot of 
valuable lessons from this one. JPL doesn't run this 
particular test very often, and we should have reviewed 
their test procedures thoroughly before allowing our 
spacecraft to undergo testing. Because this was a non- 
feedback test, it should have been standard procedure to 
run a mass simulation before running the test on our 
spacecraft, and if we had been thinking straight, we 
would have required that. (Now, 1 don't care who tells 
me something, I insist on seeing it verified.) In the end, 
the Board concluded that my team was partially respon- 
sible for the accident, and I agreed with them. 

PUTTING HESSI BACK TOGETHER AGAIN 

I didn't just accept responsibility for our mishap; I 
accepted responsibility for getting the project back on 
track. And if I was going to do that, I couldn't wait for 
someone to tell us what to do; we simply got to work. Our 
standard support structure (a machined aluminum main 
support ring) had broken in two places on each side; the 
test snapped it. So, the structure had to be replaced. But 
that was only the beginning of our problems. 

Then there were the arrays. This was a solar mission 
designed to explore the physics of solar flares, and we 
wanted it up in July for the peak activity of the 1 1 -year 
solar cycle. If we couldn't get up in July, we wanted to get 
up as soon as possible. Solar arrays normally require a 
long lead time. How could we get new arrays in time? 
Well, we got Goddard engineering involved. They found 
some solar cells manufactured for the Iridium constella- 
tion, which was now bankrupt. 

The next problem we faced was the instrument 
boxes. We had done a vibration that nobody expected 
these boxes to see. We went back to the vendors and 
asked, "If we do an ATP [Acceptance Test Plan], will you 


re-qualify?" They declined. "Buy another box" was their 
response. So, I had to fall back on another organization, 
the Quality Assurance Group, that I had previously seen 
as little more than an obstacle standing between me and 
my launch date. The Quality Assurance Group made me 
an offer: If they could get involved in the Acceptance 
Test Plan, they would accept the vibration and certify 
our boxes. That’s what we did. 

But our problems weren't over. Though it didn't 
break during the vibration test, two months down the 
road, our flight cryocoolcr failed. This was a commercial 
product that we had flight qualified. We still had about 
four or five of them, but we had to flight qualify at least 
one of the remaining coolers. So, we put together a tiger 
team to do another ATP and get it done as quickly as 
possible — although it was already clear that we wouldn’t 
make our launch date, that team worked miraculously, 
as far as I was concerned, and eventually they brought 
HESSI back to its original condition. 

Of course, this is just the technical part handled by 
the team. As the mission manager, the person respon- 
sible for overseeing all the project's facets, I had to be off 
doing other things — including 
reviews. For months we had 
operated under the maxim, "If 
no one tells you to stop, just 
keep going." So, we had kept 
working all along, but if we 
were to complete our work 
on HESSI, I needed to have 
our Recovery Plan approved. 

So, while all the technical 
work was progressing, I 
made our case in front of 
several review panels. 

After an independent 
panel gave us their stamp 
of approval in May, the 
Goddard Program Management 
Council held a Reconfirmation Readiness Review in 
June. An independent expert concluded that we 
probably only stood a 60 percent chance of surviving 
launch. When you take that to senior management, it's 
likely to be considered too high a risk. We had to 
convince them that we understood the system better 


1 didn't jus t accepi 
responsibility for 0 
misha P; I accepted 
re spo nsibility for 
Siting the project 
back on track. 


ASK 18 FOR PRACTITIONERS BY PRACTITIONERS 11 



than anyone else did. And you know what? They 
accepted this risk; here again, was another organization 
that I gained a new appreciation of. 

After that, we had a NASA Reconfirmation Review 
in August, led by Dr. Ed Weiler, then Associate 
Administrator for Space Science. I 
had to ask him for the money we 
needed to get to launch. I gave a 
presentation and when we got to 
the slide that showed HESSI 
before we started the repairs, he 
told me it was a good thing he 
hadn't seen the slides back in 
March. “I would have cancelled 
you,” he said. But, in the end, he 
approved our plan and gave us our 
money for a February 2001 launch. All in all, I was 
astonished by the level of support from almost every- 
where I turned at NASA when I asked for help in recov- 
ering this project. 

AND EVEN MORE ASTONISHING 

A year after the mishap, we were ready. I remember giving 
myself a mental pat on the back as 1 thought about how 
well we were doing — all things considered. Then we ran 
into another series of problems. 

HESSI was scheduled to be air-launched by a 
Pegasus rocket (dropped from the belly of an aircraft 
flying 39,000 feet over the ocean). The Pegasus started 
running into problems on other launches. Our launch 
date was pushed back to June. When the time came, we 
integrated our spacecraft with the Pegasus at 
Vandenberg Air Force Base in California and then flew 
across the country to the Kennedy Space Center. We 
were just four days from launch when there was another 
Pegasus failure — this one on a DoD mission. We were 
put on hold. 

We pulled out, went back to Vandenberg to wait it 
out, and put HESSI in storage. But this time Mother 
Nature decided to test us. A major rainstorm swept 
through the area, and they had to call out troops to 
sandbag our facility because the floods were rising. The 
water kept rising — so, in the middle of the night, in the 
middle of the flood, in the middle of the rainstorm, we 
moved HESSI to another building across a swelling creek. 


We got a launch date in February 2002. It took that 
long to resolve the various problems with the Pegasus 
and to get a new place in the launch queue. Finally, we 
brought HESSI back to Kennedy Space Center. Of 
course, with our luck, we came in the 
middle of another rainstorm. We were 
waved off the first time and couldn't 
land. So we had to circle the landing 
strip with lightening flashing around us 
until, finally, we saw a gap in the 
weather. We were ready to land. 

Then we got a radio call from our 
airstrip, "There’s an alligator out there 
on the strip. You can't land." 

At this point, none of us could be 
astonished by much. We got someone 
on the ground to go out and escort the alligator off the 
skid strip. Finally, we landed — another crisis averted. 

But then we had to wait for things to dry out, 
because our ground system control had been hit by the 
rainstorm. If I hadn't wondered if HESSI was in 
someway cursed, this was enough to make me consider 
the possibility: Things began to dry up, but our ground 
support equipment had been inundated with toads. We 
had to go out there, of course, and get rid of all the toads 
and put plastic strips around everything so the toads 
wouldn't come back. We finally got to our launch date, 
the fifth of February, and we were thinking, well, what's 
going to happen today? 

COUNTDOWN 

I'll tell you what happened that day. As they say, it was 
time to "open the book" four hours before launch. So, 
we opened the book — and we were red. One of our 
ground antennas had gone down. It was mandatory for 
launch. We started working that problem, at the same 
time we had to work a series of battery temperature 
problems. We did all of this on the skid strip waiting to 
get our launch off. 

Finally, we got the antenna back and got waivers on 
the battery. We' got the plane up in the air. We were 
within two minutes of our drop zone, when I heard the 
launch manager give the abort command. Excessive 
static on voice communication with the drop plane 
caused the abort. After correcting the problem, we flew 



12 APPL THE NASA ACADEMY OF PROGRAM AND PROJECT LEADERSHIP 




around and headed back to the drop zone. We had only 
one more opportunity. 

If you've ever been involved in a situation like this, 
you’re listening to four or five different channels at 
once on your headset. You can hear everyone else 
talking about any problems they see. I was listening to 
all those voices as our plane was about four minutes 
from drop, and 1 looked back down at my telemetry and 
saw that the temperature on the batten' had finally gone 
down to the right spec. All of sudden everything went 
quiet on the net. 

All I could hear then was the launch countdown. It 
went smooth. The Pegasus was dropped with HESS1 
abroad, and in eleven minutes we were in orbit. The only 
thing I could think at that point was that the gods must 
have gotten tired of beating on us. They finally smiled on 
the little spacecraft that would not give up. 

It's been more than two years now since launch, 
and the scientists are extremely happy with their science. 
While they've studied solar flares and even taken a look 
at the Crab Nebula, I've had ample opportunity' to reflect 
back on our trials with HESSI. 

What saved us, time and again? We refused to give 
up. But besides tapping reservoirs of perseverance, I also 
learned to tap what I now like to call a project's hidden 
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The HESSI project described here in Snow’s 
story was renamed after launch in honor of Dr. 
Reuven Ramaty, a Goddard Space Flight scientist 




resources. 1 learned to work with and get help from 
organizations that 1 usually didn’t think of as 
"resources." I’m talking about Mishap and Failure 
Review boards, program management codncils, and the 
like. Before HESSI, I tended to think of them as 


mountains in the road. Bui when 1 was in a deep enough 


hole with little margins to plav with, I started to sec them 
in a different light. I asked for help, and 1 got it. • 

Lhssons 

* You can never say too much about the value of persist- 
ence in the face of adversity. All projects suffer setbacks. 
Sometimes the difference between succeeding and failing 
on a project is an inexhaustible supply of persistence. 

* When confronted by problematic situations, a project 
manager with the determination to succeed identifies 
and makes use of all available resources. That may 
include looking at governing organizations in a new light. 

Ot i s I ION 

In a crisis situation such as the one described at here at the 
beginning of the stay, what would you say to a .Mishap Board 
or Failure Review Board to gain their confidence that you could 
lead your team to overcome this setback? 


until his death in April 2001. A pioneer in the fields of 
solar physics, nuclear astrophysics, cosmic rays, and 
gamma-ray astronomy, Ramaty served as co-investi- 
gator and a founding member of the HESSI team. 
"He was a genius," Snow remembers. "And, the truth 
is, we wouldn't be where we are today if it weren’t for 
Dr. Ramaty. He really believed in this project and he 
kept pushing and pushing to keep it alive." 

Now known as RHESSI, the mission continues 
to deliver solar flare data studied by scientists the 
world over. RHESSI was the first space mission to 
be named after a NASA scientist. 
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At ITT Aerospace, in Fort Wayne, Indiana, we build many different kinds of specialty payloads, 
including some of the workhorse instruments on NASA and NOAA’s meteorological satellites. 
These instruments provide many of the pictures that you see on the evening news and 
The Weather Channel. I like to think we’re not only in the aerospace business, but also in the 
business of protecting lives and property. We take our responsibility seriously, and that means 
sometimes we have to make tough decisions. 



We’ve got a very good on-orbit history with our 
instruments. Like most folks in this business, however, 
we’ve had occasional difficulties during production due 
to various technical problems. Some years ago, we had a 
problem Tike this on the Polar Orbiting Environmental 
Satellite (POES) instrument program. In this case, our 
schedules were slipping, threatening the prime space- 
craft contractor's schedule and putting us in a potential 
cost overrun situation. 

This program had been going on long enough that 
key personnel from the teams at both NASA Goddard 
and at our offices in Fort Wayne had changed many 
times. For a while, we had an incompatible mix of 
personalities, and there was a strained relationship 
between the project teams. NASA's confidence in us was 
eroding, and that was showing in the award fees, which 
were dropping. The business implications here for a 
contractor are severe, because award fees can be the only 
profit on certain types of contracts. * iyft 

At the time, I was ITT's Director of NASA 
Programs and 1 knew that I needed to take action to 
improve the situation. I decided to make certain 
personnel changes in our program management office 
to provide a more compatible mix. I also assigned 
additional systems engineering expertise to our team. In 
short order, the relationship and performance started 
improving. Things were getting better. Then, the 
backslide began when a $10M instrument was damaged 
by electrical overstress during final acceptance testing. 

Following the root cause investigation, we thought 
we understood the problem, and implemented appro- 
priate corrective action. But when we resumed testing, 
another instrument showed damage. Now we were both 
confused and in trouble. We had two instruments that 
were damaged for reasons not understood, and we were 
uncertain where the overstress had occurred in the 
testing. Once again, our schedule was threatened. 

The team faced internal pressures to hold schedule 
because ITT was involved in a competition for a new 
project. Past performance to schedule was a critical 
element of the competition. Should we try to "limp 


along” with instrument testing to make at least some 
level of schedule progress in parallel with trouble- 
shooting the problem — or should we take the more 
radical approach and shut down all testing while we 
investigated? What would ITT senior management 
think if we shut ourselves down when they knew we 
were already in schedule trouble? What would NASA 
management think if we shut ourselves down? As the 
Eagles put it in their song “Hotel California," the 
decision “could mean heaven or it could mean hell." 
What do you do? 

The Skies Begin to Clear 

A decision of this magnitude would affect the entire 
team so everyone’s voice was important in making this 
decision, i assembled the project team, including techni- 
cians, engineers, scientists, and business management — 
and we discussed the situation. We all agreed that we 
needed to do the right thing, no matter what. The 
decision, as you would suspect, was unanimous. We 
would shut ourselves down while we investigated We 
could not put additional flight hardware at risk. While all 
agreed it was the right thing to do, both NASA and ITT 


Inspection of the POES, NOAA-M, 

Resolution Radiometer (AVHRR) instrument scan minor. 
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The decision " could mean heaven or it could mean hell " 


management hoped that the problems would be found 
and resolved quickly. 

We worked many long days trying to understand 
the causes of the problem using a cooperative team of 
both ITT and NASA experts. What we found was not 
just one, but up to three potential causes of electrical 
overstress. Taking corrective action for one did not 
correct the others. All of these issues were caused by 
recent changes made in the test process. Misleading 
symptoms compounded the problems. The initial 
electrical overstress that we were subjecting the instru- 
ments to resulted in greater stresses and damage once 
the instrument was powered on. The power supplies of 
the instrument itself were causing damage due to the 
first overstress, which was weakening the part. 

The investigation showed that we had recently 
"improved” our test labs to reduce the susceptibility to 
voltage transients. In keeping with the adage that "one of 
the biggest causes of problems is solutions,” we found 



As a NASA contractor, LARRY GOSHORN successfully 
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and POES meteorological satellite sensor programs. In 2003, 
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Aerospace/Communications in Ft. Wayne, Indiana-after 
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Goshorn’s story, “A Stormy Situation," was originally presented at the 7th 
APPL Masters Forum of Project Managers, held in Annapolis, Maryland in 
August 2003. Many of the stories in ASK Magazine originate as Masters 
Forum presentations, including the story by Frank Snow this issue, “Fixing 
What's Broken.” The Masters Forum is held twice a year, bringing together 
some of NASA and the industry’s top project managers for three days of 
knowledge sharing. 

We featured a brief story by Goshorn in Issue 15 of ASK, about a team- 
building exercise involving an elephant, three managers, and a front page 
story in the New York Times about a troubled NASA program. It was originally 
told impromptu at another Master Forum, and has probably been retold by 
the people who were there more times than they can count. (Find the story 
online at appl.nasa.gov/ask/issues/15/stories/good davis.html.) 
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an adequate bleed-off path. We also found that this 
cabling was susceptible to cross-coupling any damaging 
static charge on one wire to other wires in the cable, 
potentially causing further stress. All of these issues were 
factors in our damaged instruments. 

After the first instrument was damaged, we stopped 
the investigation when we found conclusive evidence of a 
cause and corrected it. What we did not do was dig deeper 
to investigate the possibilities of multiple causes and 
eliminate them all. Following this last round of exhaustive 
troubleshooting and repair activities, which took over two 
months, the ITT team presented its findings to a NASA 
review board explaining the issues, the findings, and the 
corrective actions taken. Our final statement was, “We 
now feel that it’s safe to resume testing." 

The board agreed with us, and testing was success- 
fully resumed and has been fine ever since. We resumed 
instrument deliveries and we were able to recover the 
lost schedule in about ten months. Fortunately, we 
escaped impacting the spacecraft-level test schedule. 

A Forecast for Success 

Because all of us, the government and the contractor, 
were working together, we were able to take a synergistic 
approach to problem solving, even in a pressured 
environment, and to agree on what we were doing and 
why. Perhaps one of the biggest lessons for the team was 
that even some of the bleakest-looking situations can be 
overcome when you combine the right level of leader- 
ship, teamwork, and persistence with a few tools from 
your toolbox. It was not a comfortable decision to make, 
but it was the right decision to shut ourselves down. 

After this episode, our award fee started moving in 
the right direction, and has returned to the excellent 
range. The ITT and NASA/NOAA program teams 
continue to work diligently together in producing some 
of the best meteorological products in U.S. history. 

Lessons 

• Leadership requires courage to make the right 
decision, even if it is a painful decision. 

• Involve the entire team when making critical decisions. 
"Involvement” means open and honest communications 
that include internal and external customers. 

Question 

Would you have shut down the project after the first instrument was 
damaged, the second one, or only after a third? 
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A WHILE BACK, I WAS WORKING ON A TEAM TO 


reengineer the Air Force’s logistics process for all the 


reparable items in the inventory, everything from engines 
to oxygen regulators to electronic circuit cards. After 


doing some analysis, some experimenting, and some 
prototyping, we were ready to implement our changes. 


In simple English, we were trying to put a process in 
place where, like Wal-Mart, every customer purchase 
provides the tug that causes a replacement to be shipped 
overnight from the warehouse to fill the hole on the 
shelf before the store opens the next morning. Then, in 
response to the hole that's just been created in the 
warehouse, the depot either buys or repairs a unit and 
quickly ships it to the warehouse. By implementing this 
"Wal-Mart solution” we were sure we could make the 
whole system respond quickly to the needs of the war- 
fighters using the items. Although most people under- 
stand this process today, at the time it was revolutionary. 
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Mv team and 1 started by explaining all the flaws in 
the current procedures and processes, and what we 
needed everyone to do differently to address these 
problems. We laid it all out in neat, logical presentations 
and traveled the globe to make sure everyone got the 
message. But still, the masses soldiered on, continuing to 
behave in the same old ways. 

At that time, the entire system was based on 
forecasted demands. Once a year, the item managers, who 
were responsible for ensuring that depot repairs satisfied 
demands, met with the war-fighters' staff at a workload 
conference to predict what would be needed the following 
year. Armed with last year's data and an enormous set of 
computerized forecasting algorithms, they agreed on what 
would be repaired during the upcoming year. The item 
managers then met with the depot repair shop chiefs, who 
were required to keep all their people and machines 
gainfully employed, and negotiated a workload plan. 
Things had been done this way for the last forty years. 

Everyone recognized there were problems with 
the process. Actual demand always turned out signifi- 
cantly different than what was forecasted, leaving the 
war-fighters with things they didn't need and holes they 
couldn't fill. Assuming that a more accurate forecast 
was the only way to improve the situation, every year 
smart people got busy building 
a better forecast. Yet, after 
spending millions of dollars vear 
after year to incorporate more 
data and increase the complexity 
of the computer algorithms, the 
problems persisted. 

This was the state of affairs 
when we arrived with our 
proposed changes. After months 
of explaining, and wrestling with 
the item managers to change 
their process, I was feeling 
extremely frustrated because it 
seemed that despite our best efforts, we weren't getting 
anywhere at all. If anything, we were going backwards. 

That’s when I went to visit Chief Steve Haskin. Steve 
was sharp, full of energy, and above all, practical. He had 26 
years of Air Force experience, grew up in Texas in the heart 
of cattle country, and I could always count on him to 
provide me with sage advice. 

As I explained my concerns and frustrations, Steve 
interrupted me and said, "Sir, the first thing you have to do 
is get the cows on their feet." 


I’ll never forget that comment. It floored me. I just 
stared at him with what must have been an amusing 
expression because Steve laughed out loud before 
explaining: "When you're herding cattle, the first thing 
you have to do is get them up off the ground and 
moving. Then you can worry about heading them 
around in the direction you want to go. 

"I think we need to do the same thing,” he 
continued. "We need to get these people off their feet 
and moving. They’ve been lying here doing the same 
thing for the last forty years.” 

It was a clarifying moment. We had been trying to 
explain logically what changes needed to be made and 
why. Now, with Steve's help, I realized we had to find a 
way for them to see it themselves — we had to get them 
on their feet. What was needed was some sort of prod; 
whether it herded them into the right pasture was irrel- 
evant, but we needed a prod that would get them 
up on their feet. 

As luck would have it, just that morning we had 
demonstrated a new computer system that would let 
all the item managers and the repair shops sec exactly 
what “holes” existed at each war-fighter base location. 

I grabbed a few key members of my team, and after 
making an animated, emotional appeal, got the 
general’s permission to provide 
this information to all the repair 
shops, and tell them they could 
only repair something if it 
appeared on this list. 

It worked! Predictably, the 
item managers went ballistic. 
For them, success had meant 
delivering what they had 
promised the war-fighters at the 
workload conference, but now 
the repair shops wouldn't be 
paying attention to the negoti- 
ated quantities. All that mattered 
was the list of the war-fighters' "holes.” The shop chiefs 
weren't happy, either. In their world efficiency was king. 
Success depended on efficiently using all the shops’ 
budgeted hours, but how could you efficiently plan the 
work when you were given a new "to do” list each day? 

There were many questions, and we addressed them 
all as we met with both the item managers and the shop 
chiefs. Eventually we worked out a compromise where the 
shops repaired only what was indicated on the "holes” list 
each day, but the requirements were prioritized each day 



BY IMPLEMENTING THIS 
“WAL-MART SOLUTION” WE WERE 
SURE WE COULD MAKE THE 
WHOLE SYSTEM RESPOND 
QUICKLY TO THE NEEDS OF THE 
WAR-FIGHTERS USING THE ITEMS. 
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I REALIZED WE HAD TO FIND A WAY 
FOR THEM TO SEE IT THEMSELVES- 
WE HAD TO GET THEM ON THEIR FEET. 




by usage-predicting software algorithms. It wasn't the 
perfect solution, but it was an excellent short-term win. 
Everyone from the war-fighter staff to the shop workers 
quickly saw the benefit of letting actual customer demand 
drive the repair process. 

In a few short months, we stopped repairing 
equipment no one wanted, and focused on what was 
actually needed. In the next year we eliminated $798M of 
inventory and reduced delivery time to the war-fighters by 
more than a third. But more importantly, this first step got 
everyone on their feet and moving. Without that, we 
would never have been successful in rounding everyone 
up, coordinating their efforts, and moving the Air Force's 
logistics system in this new direction. • 

Lessons 

• There comes a point where you have to stop talking 
about what you're going to do and just give it a try. Results 
will change beliefs much faster than words or briefing 
charts. 

* Most people won't willingly jump into something they 
don't understand, don't see a need for, or aren't confident 
they can excel in — you have to give them a push. 

Question 

Is it time to stop talking and take action on your idea? 


m -* SOLD ON STORY 

me A professor of program management and leader- 

b ship at the Defense Acquisition University (DAU), 

r \ *; MAJOR NORMAN PATNODE believes that 

stories accelerate learning in areas such as 
leadership, risk management, and teamwork. Recently, Patnode put 
his theory to the test when he introduced the concept of learning 
through story to fellow DAU staff. With support from the Academy 
of Program and Project Leadership (APPL), Patnode organized a 
Knowledge Sharing Workshop in December 2003 modeled on 
similar programs run by APPL at NASA centers. 

The workshop was a big success. Patnode reports: “We had nearly 
thirty folks participate, and their comments were all positive. Many 
shared with the group how they planned to start using stories both 
in their classrooms and in their group facilitation work." 

Patnode’s respect for story has another APPL model, as well-the 
semi-annual Forum of Master Project Managers. “I gained a tremen- 
dous amount when I was invited to the Masters Forum," explains 
Patnode. “While I was there, I learned much from the wonderful 
stories that were shared so openly. Since then, as I’ve reflected on 
those stories and how I can apply them to what I do, I continue to 
find new insights. It seems that each time I reach up and pull one of 
those stories back out of my memory, a bunch of other related 
stories come tumbling down as well, so I end up reflecting not only 
on the original story, but a web of interrelated stories. That’s the 
beauty of it-learning from stories is multi-layered and never ends." 
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FIRM FIXED PRICE (FFP) CONTRACTING IS A SPORTY PROPOSITION. AN FFP 
PROGRAM THAT IS SIGNIFICANTLY OVERRUNNING WILL BRING A COMPANY TO 
ITS KNEES. CONVERSELY, WHEN SUCCESSFUL, PROFITS CAN BE SUBSTANTIAL. 


At starsys, we execute many ffp programs for 
the development of mechanical systems for spacecraft. 
Contracting this way presupposes that we have the 
ability to establish and hold scope for a system that has 
yet to be defined. To do FFP, it is critical that we have 
program managers who are masters at cost control. 

Fortunately, we have some "masters" in our 
company. They just seem to have a knack for driving to 
a financial target. Doesn't matter if the program has 
contingency or not. Doesn’t seem to matter if they use 
MS Project, Excel spreadsheets, or the back of an 
envelope. Doesn't even seem to matter whether the 
program is set up as a financial challenge or a winner. 
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Yes, they have systems and the mechanisms for 
converging on a cost target, but so do the good — but not 
master — program managers. 

As I looked back over the last five years, it was clear 
that some of our program managers consistently 
generated great results and others did not. This got me 
to thinking, if 1 could only figure out their formula, 
could it be turned into a recipe for success? I started 
talking to some of the managers about this, and one of 
their comments struck a chord, “You just do it — 
it's natural, it's where the fun is.” That got me thinking: 
Maybe this isn’t as much of a skills issue as I had 
previously thought. 



It's accepted practice that good engineers are 
created not born. That's what engineering degrees are 
all about. But this is not always the case for other 
disciplines. Take marketing: These folks seem natural 


a contract element. Try to get a great designer excited 
about a favorable negotiation of a contract element! 

Now, whenever I interview a project manager there 
are a couple of things I know to ask to gain insight into 
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at it. They love meeting people, they love developing 
relationships, they love explaining things, and they love 
enrolling people in their ideas. Could it be that master 
program mangers are born not made? 

Maybe Myers-Briggs would have the key. I had a 
group of fifteen folks take the Myers-Briggs personality test. 

The group included good program managers, the ones 
I regarded as masters, and others who had demonstrated 
that their strengths lie elsewhere. And the result was... no 
correlation! Yes, I could see some patterns that explained 
the individual’s styles, but clearly Myers-Briggs was not an \ 
indicator of who was a master program manager. 

I spent a lot of time talking to these masters. What I 
found were shared values. The things that they found 
fun, interesting, and worthy had some common threads. 

For instance, they all loved business and the game of 
leveraging what you know to make money. And that 
interest went way back. These were the folks with the 
lemonade stands, the newspaper routes. I was surprised 
by this. Values are the beliefs that develop as a person is 
growing up, from the primary influences in your life 
through grade school and high school. 

Their similarities carried on into college. The masters 
were those who had wanted their MBAs. It wasn't so 
much what they had learned from their MBA as it was 
their passion about getting one. To a person, they had all 
thought about starting their own business, but for 
whatever reason had chosen to take a less risky path. 

The most interesting thing was what really made for 
a "great day” for these people. It wasn’t limited to finding 
a great design, or converging on a technical solution. 
Business wins were the things that made them smile, 
high-five, and carry on about how much they loved what 
they did — finding the technical solution that would save 
$50,000 or that resulted in the favorable negotiation of 


their values. For instance, I’ll ask, "So, did you ever run 
a lemonade stand?" 

Some folks look dumbfounded. You may as well be 
asking them to talk about their root canal. But masters 
"light up” at this point and respond with something like, 
"Oh yeah, ever since I was a kid I loved making money." 
Masters tend to think in terms of leveraging what they 
know to create an enterprise that makes money. I don't 
just ask them about their lemonade stands, but it's not 
such a bad place to start. This is values-based inter- 
viewing, and it is actually an easy way to get at what 
makes people tick. 

H. Yes, we need to give our project managers the right 
resources — the tools, the qualified technical expertise, 
and the training — but it's a mistake to assume that we 
^can “grow" any given engineer into an effective project 
manager. We put our projects at risk if we do so. The 
lesson here is that we must seek out PMs with a passion 
for the business of projects. This is something to 
consider, too, as we recruit and groom tomorrow’s 
project leaders. 

Business wins were the things that made them 
smile, high-five, and carry on about how much they 
loved what they did. • 
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The first solar plane we developed at 
AeroVironment was named the Gossamer Penguin. 
The word “gossamer" was an apt description of the 
appearance of this strange-looking aircraft that had a 
structural weight of only 54 pounds, with a wing span 
of 71 feet. 

Much was sacrificed to save weight and maximize 
span, and this presented serious problems when 
handling the aircraft on the ground. The Penguin was 
barely strong enough to stay together in the light winds 
and low turbulence of the early 
morning. Moving the Penguin 
back to the hangar at the end of 
a morning flight was much like 
walking a 71 -foot span kite 
home from the park. 

To move the aircraft about 
on the ground, as well as to 
stabilize it during take off and 
landing, we needed to come up 
with a lightweight solution. An 

obvious one would be to assign "wing walkers” to mind 
each wing tip. A walker would simply pull down on the 
wing that was being lifted up by the gusts. The tips of the 
Penguin, however, were over eight feet above the 
ground. If the aircraft was allowed to tip far enough to 
one side for ground crew to hold it, then it would have 
already raised the other tip high into the wind. At that 
point, the aircraft was likely to flip over. 

To solve that problem, we used a string of Kevlar* 
tied to each tip. It was extremely light and thin, so 
the performance penalty of carrying the string along in 
flight was negligible. Unfortunately, this elegantly simple 
solution had one minor flaw, which, like all such flaws, 
was discovered the hard way. 

When the winds were calm the string worked very 
well, and kept the wings level and away from the ground. 
But when a strong wind caught us walking the Penguin 
home, it required some tension on both strings simulta- 
neously to keep it balanced on the dolly set under the 
main wheel. Accordingly, the walker would get used to 
holding the string at a certain height and a certain 
tension, and when a gust began to lift his wing up, he 
would feel the increasing tension in the string, and 
naturally react by pulling down harder on the string. 

Sometimes one wing walker would pull down 
inadvertently, which pulled the opposite wing up 
slightly. Feeling this tug, the other walker would assume 
a gust was hitting his wing, and would begin to pull 


“I’ve found over and over again 
that the most common solution 
to problems in any group of 
people that must work together 
has been better communication.” 


down harder on his wing to prevent the wing from 
lifting more, and getting even more lift as the wing rose 
higher against a side gust. The first walker would now 
feel a strong pull on his wing and would resist even 
harder. Since the wings weren’t designed to take large 
point loads near the tips, a disaster seemed imminent. 

The fix didn't require a high-tech solution. After 
discussing the problem, the flight team realized that by 
simply having each wing walker alternatively call out an 
estimate of how hard they were pulling on their string, 
they wouldn’t fight one another. 
When the flight team tested the 
system, they discovered that it 
didn't even matter if the walkers’ 
estimates were accurate; they 
just needed a rough idea of the 
balance of their efforts. 

In practice, as a pair of 
walkers got used to working 
together, they rapidly developed 
a sixth sense that made their 
estimates surprisingly close. But this job could quickly 
get boring, which meant we often changed walkers 
during a test day. Fortunately, we found that any new 
team of walkers would quickly calibrate each other after 
only a short orientation. The result: no broken wings. 

The Gossamer Penguin solar-powered aircraft was 
my first project management experience. Since that 
time, I've found over and over that the most common 
solution to problems in any group of people that must 
work together has been better communication. 
Sometimes it’s a system or process, sometimes it's an 
attitude adjustment, but improved communication 
almost invariably helps a team be more productive and 
effective. Just as importantly, it generally makes the work 
a lot more fun. • 


RAY MORGAN is head of Morgan Aircraft & 
Consulting and a senior technical advisor to 
NASA. Morgan oversaw the development of 
over 35 Unmanned Aerial Vehicles (UAVs), 
including NASA’s Helios and Pathfinder 
aircraft, during his tenure at AeroVironment, Inc. His first 
ASK feature, “Coming of Age,” appeared in Issue 16. 
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SPECIAL FEATURE: THE POWER OF STORY 
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ASK Magazine is not alone when it comes to using storytelling to capture lessons learned and share knowledge. Several other practitioners 
have successfully introduced this approach to knowledge management within organizations. This article by Annette Simmons marks the first in 
a series by authors whose work on storytelling has been widely recognized. We hope these features illuminate why ASK contributors use the 
story form to share their knowledge, and how you can do the same. Annette Simmons spoke at the February 2002 APPL Masters Forum. 


I WENT TO MY FIRST STORYTELLING FESTIVAL AS AN ADULT. My DAD THOUGHT IT WOULD BE A GREAT PLACE FOR THE 
family to get together, so he sent us all tickets. I can still recall sitting inside the festival tent and noticing the rapt 
attention of the people around me as a story was told. Jaws slackened, whole bodies became receptive. We were 
trained on every single word that came out of the storyteller. That’s when I understood the power of storytelling. 

I first began to study storytelling so that my presentations wouldn’t be boring — but as I worked on story- 
telling, storytelling started to work on me. There’s something important going on here, I realized. But how do 
I describe it? With a story, of course. 


Truth, naked and cold, had been turned away from every door in the village. Her nakedness frightened the 
people. When Parable found her she was huddled in a corner, shivering and hungry. Taking pity on her, Parable 
gathered her up and took her home. There, she dressed Truth in story, warmed her and sent her out again. 
Clothed in story, Truth knocked again at the doors and was readily welcomed into the villagers’ houses. 
They invited her to eat at their tables and warm herself by their fires. 

— Jewish Teaching Story 
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We need stories because cognitive learning doesn't 
always cut it. If it did, any of us who wanted to lose 
weight would only need to read one diet book. People 
don’t have flip-top heads that open up for you to shove 
information down. We’ve tried that — at least I have. My 
first ten years in management experience I worked that 
way. It doesn't work. 

Story is one of the most respectful ways to share 
knowledge, and thus, one of the most effective because 
it allows people to come to their own conclusions. 
Instead of telling someone, "You should be more 
patient,” you invite your listener to come to that conclu- 
sion independently: "Hey, I know what the problem is. 
My impatience is making things worse." 

WE NEED STORIES 
BECAUSE COGNITIVE 
LEARNING DOESN’T 
ALWAYS CUT IT. 

And who amongst us doesn’t need more patience? 
Yet, preach "Be more patient, be more patient," to a 
bunch of smart executives, and I’ll guarantee increased 
patience will not be the first change you begin to notice 
in their behavior. 

So take them on a journey, instead. Here’s 
another story: 

A woman begged the shaman for a potion to 
make her husband love her again. She explained that 
before her husband fought in the war, he was warm, 
loving, and he laughed easily. But since his return he 
was angry, distant, and humorless. The more she tried 
to hug her husband, tease him, and draw him back to 
her, the worse it became. The shaman was her last 
hope. He listened patiently to the woman’s story. 
When she was finished, he said, "I think I can help 
you. I will make you a love potion — but you must go 
find one of the ingredients." She said she would. Then 
he told her to get a whisker from a live lion. She was 
distraught, "How can I possibly get a whisker from a 
beast as fierce and powerful as a lion?” The shaman 
shrugged and left her to her tears. 

The next day she went to a place where she had 
once seen a lion. On that day she saw nothing more 


than monkeys fighting in the trees and birds flying in 
the air. On the second day, she stayed a little longer 
and found a comfortable place to sit. But she did not 
see the lion. Weeks passed. One morning she sensed 
the lion’s presence before she saw' him. She didn't 
move but the lion saw her anyway and ran away. It was 
a week before she saw him again. Curious, the lion 
stopped running away. Finally, after weeks of bringing 
the lion good things to eat and ever so slowly reaching 
out to pet him, he finally was so comfortable with the 
woman that he fell asleep under her stroking hand. 

Once he was asleep she took a very sharp knife and 
gently cut one single whisker from the lion’s muzzle. 

The next day she brought this whisker to the 
shaman, and asked for the potion that would make her 
husband love her again. The shaman said "You do not 
need any potion. Throw away the whisker, keep the 
knowledge you have gained, and your husband will 
learn to love you once more.” 

— Somali tale from Ethiopia 

Now, that’s what I would call a teaching story. So if 
you’re trying to teach someone how to be a good project 
manager, handing out a list of dos-and-don’ts will never 
encompass the subject the same way as one of your 
personal stories about when you learned something 
about project management. • 

■ ANNETTE SIMMONS is the President 
of Group Process Consulting and the 
author of three books, The Story Factor 
(2001), A Safe Place for Dangerous 
Truth: Using Dialogue to Overcome Fear 
& Distrust (1999) and Territorial Games: 
Understanding and Ending Turf Wars at Work (1997). 
Her books have been translated into several languages, 
and she travels regularly around the world to speak 
about her work, much of it concerning the use of story- 
telling in organizations. 

"Whether you’re proposing a risky new venture, trying to 
close a deal, or leading a charge against injustice, you 
have a story to tell,” says Simmons. "Tell your story well 
and you will create a shared experience with your 
listeners that can have profound and lasting results.” 

Simmons combines public speaking, writing, consulting 
and constant research and development to serve organ- 
izations seeking to increase workgroup cooperation for 
bottom-line results. Her latest book on women in organ- 
izations is scheduled to be released later this year. 

Annette Simmons can be reached at annettegpc@aol.com. 
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I FIRST CAME TO THE JET PROPULSION LABORATORY (JPL) 
48 years ago, and was taught that what's most 
important for project success is bringing good people 
on board, getting them to come together as a team, 
making certain that they're all on the same page, and 
setting up the mechanisms to keep them communi- 
cating. That much is true to all successful projects — 
but, naturally, it's not as simple as it sounds. 

What, for example, are the most effective 
"mechanisms” for communication? Today, people 
think about email when they think about day-to-day 
communication and PowerPoint for presentations. 
But many believe, including me, that the advent of 
email and PowerPoint has, in some respects, eroded 
our culture of engineering communication. 


Of course, if you need a quick answer, if you're 
working with remotely located team members — 
then email can be a tremendous communication 
tool. So is PowerPoint for presenting an engineering 
summary or presenting the results of a design 
activity. But what's important to note here is that 
neither email nor PowerPoint is an adequate substi- 
tute for engineering documentation. 

By that, I mean if you have people working in a 
technical area, it doesn't matter what it is, at 
periodic times you need to have them capture the 
engineering that has gone on. You need to do that 
with an engineering memo, or a workbook, or a 
technical report — whatever you want to call it. You 
need to do that to provide an audit trail of decisions 
that that can be reviewed and challenged by peers. 
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For the record 

A technical memorandum is what we used to call it. 
We used to have a form for the engineers; they 
would put their summary at the top, list their 
assumptions and the boundary conditions next, and 
then go through the analysis — sometimes even 
including a summary of some of the equations 
involved, plus the pros and eons they had consid- 
ered. All of that preceded their recommendations 
and/or summary of actions taken. 

That became a part of the engineering file. 
Anybody could go back and review that or challenge 
it. You could say, "Okay here is the analysis." You 
could give it to another person or to another group 
and have them validate it or critique it. It also stood 
as a good way of handing off information about work 
that had been done to a newcomer on the project. 

What I've seen over the last ten or fifteen years has 
been a gradual erosion of the discipline of that kind of 
engineering documentation. Again, I think it has a lot 
to do with the introduction of email and PowerPoint— 
which, once again, are tremendous tools for commu- 
nicating but not for engineering documentation. 
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The Mobile Service lower is being rolled away from the Titan 
l\ B/Ccntauv launch vehicle carrying the Cassini spacecraft. 


One way of putting it is that email and 
PowerPoint are more like sound bites. You can't 
critique a PowerPoint presentation the way you can 
an engineering memo. It simply doesn't have the 
structure and the completeness that you would find 
in a report or a memo. In many ways communicating 
has become easier, but it's still necessary to keep 
track of where you're going and the decisions that 
have been made. 

But does it really matter? 

Let me give you an example of a time when commu- 
nication was at the root of a project's demise. 1 was 
on the Failure Review Board for the Mars '98 
failures. The Mars Climate Orbiter failure was 
ostensibly caused by a metrics conversion error that 
led to a navigation failure. We were getting the 
navigation data by tracking the spacecraft to 
calculate the trajectory. The data that we got from 
the spacecraft augmented the data from the 
ground — but there had been some inconsistency 
noticed during the mission well before the failure at 
Mars orbit insertion. 

When we observe an inconsistency during 
operations, our practice is to use an engineering 
reporting system, called an Incident Surprise 
Anomaly (ISA) report, to record the discrepancy. It's 
only one page long, but it's a formal report. Once it's 


submitted, it gets tracked. During the course of a 
mission there may be 100 or even hundreds of IS As. 
Once you write an ISA it becomes a permanent 
record in the system. It gets reviewed. Its ongoing 
status gets reviewed. Its closure gets reviewed. People- 
have to buy off and say, “Yes. this Incident Surprise 
Anomaly, whatever it was, is understood now. We 're- 
taken the following steps to prevent it from 
happening again and we’ve corrected whatever it is." 

In the case of the Orbiter, the person who 
noticed this problem didn't use the ISA form. He 
wrote an email message to the person that he 
thought could solve the problem. That person got the 
email message, and he looked at it and worked on it 
for a while. Then his boss gave him something else to 
do that this individual judged to be of higher priority 
than working on the problem outlined in the email. 

I lere is a case where the guy who noticed the 
problem thought he was doing the right thing. He 
wanted to get the problem taken care of quickly. He 
sent the email out. The email went to where the 
spacecraft was being worked. The guy who received 
the email probably could have solved the problem. 
But he didn't. It got forgotten. 

If that message had been generated as an ISA, it 
could not have been forgotten. It would have become 
a permanent part of the engineering documentation. 
In our failure review report, we described the 
problem something like this, "Communication 
channels among project engineering groups were 
too informal.” 

No one would argue that open communication 
is key to project success. What I'm suggesting is that 
we keep in mind that communication comes in many 
shapes and sizes — it's not a one-size-fits-all concept. 
We need to reinforce the distinction between the 
need for rapid communication and the need for 
engineering documentation, which creates products 
that can be peer reviewed and that leave an audit 
trail for engineering follow-up and close-out. • 
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JOHN CASANI came out of 
retirement in 2003 to return to 
the project management ranks 
at the Jet Propulsion Laboratory 
in Pasadena, California. The 
engineering memos Casani champions in this 
article are far from being the only formal commu- 
nication he sets up on his projects. 

“As a project manager, I hold two regularly 
scheduled meetings each week,” explains 
Casani. “One is with just the core project staff, 
and the other gathers a more extended set of 
people working on the project — including people 
matrixed to the project from each of the major 
technical areas* 

In addition, the full project staff— including out- 
of-town team members from other NASA 
centers, government agencies, industry, and 
academia — are invited to monthly meetings and 
many of them make a point of attending the 
meetings in person. “This is the way that we can 
coordinate and keep track of how the project 
is going,” says Casani. “We keep everyone 
informed about what everyone else is doing.” 

Informal communication is just as important. 
Core team members are co-located in “our own 
comer of the building,” says Casani. "We’re in 
contact every day, almost every hour, in addition 
to the meetings we hold." 

For more about John Casani’s remarkable 
career at JPL, see his story, “A New Spin,” in this 
issue (page 6). 
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Following the release of the Columbia Accident 
Investigation Board (CAIB) Report, Alphonso (Al) 

Diaz, Goddard Center Director, was asked by NASA 
Administrator Sean O'Keefe to head up the Agency's 
response. The Diaz Team, as it came to be known, was 
charged with making sure the CAIB Report did not 
become another dusty volume on a shelf of old 
Agency Reviews. 
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Al Diaz was appointed Goddard Center Director in In 1979, Mr. Diaz began his work at NASA 

January of 1998. Before that, he served as Goddard's Headquarters, where he served in a variety of leadership 

Deputy Director, beginning in 1996. Mr. Diaz began his positions, including program manager on the 

career at NASA’s Langley Research Center in 1964, International Solar-Polar Mission (now known as the 

where he worked in a variety of technical management Ulysses Mission) and Galileo. Mr. Diaz has been awarded 

positions, principally on the Viking Program as the lead three Presidential rank awards, two as Meritorious 

for Gas Chromatograph Mass Spectrometer. This Executive and one for Distinguished Service. He was also 

scientific instrument was the first to analyze the surface awarded a NASA Outstanding Leadership Medal in 1 994 

material on Mars in 1976. for his work on the Hubble Space Telescope first 
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IS M anaging or leading entails the responsibility to have 
a justification for what you're doing and to be able to 
articulate that justification in a way that nine times out 
of ten is not going to be second-guessed. #7 
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The Agency wanted to know if behaviors like the ones 
cited in the CAIB report existed on a broader scale than 
simply the Space Flight Program. 

How did you go about collecting information? 

The team recognized that we needed input from other 
people, in terms of what they thought about the CAIB 
report and what they extracted from it. We engaged 
Headquarters. We engaged field center directors and their 
staffs. We talked with individual managers. Then we held 
a Safety and Mission Success Week, which got everyone 
at NASA focused on safety and mission success, at the 
same time it provided us with an opportunity to hear their 
thoughts about the relevance of the CAIB report. 

I think we’ve got to be clear about what the team 
was asked to do: Find out what, if any, of the CAIB 
recommendations had broader applicability. Then, to the 
extent they did, what should we do about it as an Agency? 


Our charter ends with the identification of a set 
of recommendations we extracted from the CAIB 
report that could be applied Agency-wide. Subsequent 
implementation planning will have to determine how 
best to execute those recommendations. It is my 
expectation that there will be differences in the way 
things are applied, but that there will be some standards 
set across the Agency. 

So then, a five-person project shouldn’t necessarily 
expect to be addressing the same concerns as say a 500- 
person program ? 

There is always this concern that we’re going to come 
out with an overly constraining set of recommendations 
that will squeeze out all of the creativity and flexibility on 
a project. We have no intention of doing that. 
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Technicians at the Johnson Space Center in Houston team up to assemble a test article to simulate the inboard 
leading edge of a Space Shuttle wing as part cf the Columbia Accident Investigation Board's testing. 


Did identifying those u widely applicable" CAIB 
recommendations come down to a judgment call based on 
the collective experience of your team? 

It’s safe to say that we had a good deal of directly applicable 
experience among us. The example I like to use for that is 
the RCC [reinforced carbon carbon] panels. As one of the 
recommendations to address the physical cause of the 
accident, the CAIB report suggested that the Shuttle 
program make certain in the future that there are sufficient 
RCC panels available that meet all of the specifications, so 
that program people don't have to make decisions about 
using hardware that has lower integrity than required. 

Well, we don't have RCC panels anyplace other 
than the Space Shuttle Program, but we do run into 
situations where the perception that a program is 
resource constrained influences us to put ourselves in 
the position where we have less hardware than we ought 
to have when making decisions about selecting 
detectors or other flight parts. 

I don't know how many times we’ve been through 
this process of asking, "Well, can we use a non-flight 
part in this application because it would take 26 months 
to order a new part?" You put yourself in a position 
where you have to make those compromises sometimes. 


So, we observed that the recommendation has 
broader applicability than the Human Space Flight 
Program — not because the RCC panels are used 
everywhere, but because of the implications: People 
shouldn’t be put in positions where they need to 
compromise on critical components. We relied on our 
own experiences to reach this conclusion. 

Have your findings made you look at your own center, 
Goddard, in a new light? 

I have seen things at Goddard that I think bear some 
consideration. The CAIB observed that in the case 
of Human Space Flight, there was not enough 
independent technical input. That somehow the 
relationship between the engineers and the programs 
colored the input that engineering was making to the 
programs. I worry about that here at Goddard, and we've 
tried to structure our relationships so that engineering 
retains an independent voice. 

How are you attempting to address that issue? 

We went through a major reorganization five years ago. 
It was one of the first things I did here as the center 
director. We established a central engineering 
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## People shouldn’t be put 
in positions where they 
need to compromise on 
critical components, n 


problem. We think we've got to change something on 
that project because we are worried that we’ve got the 
wrong mix of people." Or, "We’ve got too few engineers 
there." Or, "Our engineers have concerns that aren't 
being addressed." 

Aren't there times when the project manager has to 
make a judgment call? Should project managers be 
concerned that it is now going to be more difficult to 
make decisions? 


organization so that we could matrix our engineering, 
in order to establish quality control over the work that 
is provided to the projects. We went through the pain 
of pulling all of engineering out of other organizations 
and bringing it to that organization. But a few of our 
larger projects — Hubble, GOES [Geostationary 
Operational Environmental Satellite], POES [Polar 
Orbiting Environmental Satellite] — haven't been 
pulled into this setup yet. I think it's time to revisit that 
decision now. 

You know, change has its risks — but not changing 
has risks, too. We made the determination five years ago 
that we were better served not to make the change on 
these projects to the new model. But, as I said, it’s time 
to take another look at this. 


If it appears more difficult, then it is probably because we 
haven’t been doing it right in the first place. I think this 
whole idea that somehow it is going to be more difficult 
because people have a legitimate right to question 
leadership is really part of a dysfunctional mindset. 

Leaders need to be accountable. If, as a leader, I 
can't tell people why I decided what I’m doing — with the 
expectation that they will support my decision, given the 
kind of record that I have — then I have a problem and 
I’ve got to deal with that problem. 

Managing to me is not simply making decisions and 
moving on. Managing or leading, I do think, entails the 
responsibility to have a justification for what you're 
doing and to be able to articulate that justification in a 
way that nine times out of ten is not going to be second- 
guessed. If engineering decides that they are not satisfied 
with something and they want to bring it to their 
management, I don't see that as second-guessing. I think 
that's just part of a healthy process. 



When engineering operates as an independent 
organization, do you worry that project managers could 
feel as though they're being second-guessed? 

I don't think the good managers feel that way. I think the 
good ones see our engineering organization as an 
important element of getting the resources that they 
need to get the job done successfully. It isn't usually a 
question of the project wanting to spend less on 
engineering, and engineering wanting more and more 
work performed. Our experience hasn't been that at all. 
Our experience has been just the opposite in that the 
project manager wants more engineering support than 
he or she might actually need. 

What happens in this scenario when they don't agree? 
Does the project manager still get to say, “Look I respect 
that you've said this, but my decision is that we go the 
other way"? 

Then the engineering organization can elect to take it to 
the Program Management Council and say, "We've got a 


What are the challenges that you see project managers 
facing at NASA today? 

Project managers work in the margins all the time. They 
are always working on budgeting what is left. They have 
a plan. The plan has reserves. The conduct of the project 
is, in essence, the management of the depletion of those 
reserves, so that every available resource is used to the 
maximum extent possible. 

The real challenge is how do you know when you 
have enough? Everybody can’t have as much as they 
could possibly imagine. So, how do you know when 
you've got enough? Our tools are limited in terms of what 
we have available to determine what the right cost is. 

How can you tell when a prefect is being managed well? 
I think it starts at the top, in terms of the competency 
and character of the leader. It has a lot to do with 
whether or not the resources that are being made 
available are adequate to do the job. 
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• communication 


That was another observation in the CAIB report. 
In these complex projects we need to maintain an 
environment where everyone feels invited to participate, 
and where what are typically called “minority opinions" 
are viewed as part of the diversity in the project that we 
welcome, as opposed to people cringing when 
somebody has a different idea. I really think the 
communications piece of a project is critical. 

While you were talking with people throughout the 
Agency, interviewing them about the CAIB report, did 
anything you heard surprise you? 

One thing for certain: We can learn a lot more by talking 
to other people than we sometimes believe. When we 
went through Safety and Mission Success Week, for 
instance, many of the issues that people raised were 
predictable. We could anticipate the categories of things 




that people would bring up. Where we did our learning 
was in the feedback process, when we listened to people 
address those issues. 

Here at Goddard, I went to each of our major 
organizations at the end of the week. I asked a cross 
section of the population in each organization, "What did 
you learn this week?" In the case of communications, 
one of the issues we discussed was the way we wanted to 
deal with minority opinions. I got an input from a young 
guy in Human Resources, who said, "You know, even the 
term ‘minority opinion' is pejorative. As a consequence 
you re not really encouraging people to come up with 
alternative viewpoints, which would really benefit you." 

And so I got to thinking about that— and I saw 
that he is absolutely right. What we need to be doing is 
not only saying that we are open to minority opinions; 
we ought to be saying that we encourage the 
development of alternative opinions so that we can test 
the prevailing opinion the same way that we do in the 
scientific method. 
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Not only that, but we need to be prepared to apply 
resources to that, not force the people that have these 
different opinions to provide the resources themselves. If 
we're prepared to apply resources to develop those 
alternative opinions, only then should we feel 
comfortable that the prevailing opinion is in fact correct. 

Is there something that can be done at the centers to make 
resources available for that? For example, what will you 
do to change things at Goddard? 

I think that part of the independent technical 
authority ought to be an allocation of resources to 
engineering that is non-specific to the task they've 
been asked to do, but is available on an unsolicited 
proposal basis for people to develop alternative 
options for projects. 

Now, it may come out of the same pool that we use 
for reviews or what have you, but we have to set aside 
some resources for general engineering review functions, 
development, and things like that. Typically, it's not 
dollars. It's workforce time. So, we're trying to think 


about how we would go about doing that as part of the 
establishment of what we will call our independent 
technical authority here. 

Let’s say you have five engineers working on a project, 
and each one of them has a slightty different idea 
about the best way to do something. Can you run down 
every idea? 

No, you can't run down every idea, but our engineering 
people do their own peer reviews. They bring people 
in and test the prevailing opinion. I think there needs 
to be a constant testing of the design and the 
development of the design. If we ever get to the point 
where everybody has a different idea, then we have a 
different problem. 

The challenge now is to recognize that the prevailing 
opinion may not always be correct. Why is it that we feel 
so comfortable when there are no minority opinions, as 
opposed to feeling good about being in a position where 
there has been a different opinion voiced? 


The STS-1 14 crewmembers look at the reinforced carbon-carbon panels fir one of the wings 
of die Space Shuttle Atlantis in the Orbiter Processing 
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Why do you think that is? 


Perhaps it's human nature. It's just more comfortable to 
feel that way. But in complex environments like ours, we 
shouldn't feel that comfortable. 

Here's an example: On the first Hubble Servicing 
Mission, we all thought we were ready. We all thought 
that everything was perfect. Then Joe Rothenberg, the 
project manager, said, “I would feel more comfortable if I 
could test this plan." So, we brought in a group of people 
from Lincoln Labs. We put together a team of around 
twenty people and said, “We want you to sit down and go 
through the reviews with the Hubble guys. If you see 
anything that you think warrants further penetration, we 
want you to develop that idea and we're going to give you 
the resources to support a team to do that.” 

And you know what? They did find something that 
they were worried about and they pursued it. In the end, 
they concluded that they were wrong and the Hubble 
guys were right. But it wasn’t a waste of time; we had 
tested our prevailing opinion. 


With die Hubble , there was a mandate that “we have to 
fix this dung." Some projects don’t have the kind of 
resources to create those kinds of (kecks and balances. 
Well, some of them don't have to do that. For instance, 
we have experts in a lot of veiy esoteric kinds of designs 
and elements of design. I'm thinking about a guy in our 
engineering organization who knows a certain kind of 
device better than most people in the world, probably as 
well as virtually anyone in the world. 

In the past, he might have gotten the impression 
that people cringed when he showed up at reviews 
because he was always so penetrating and precise about 
the use of this particular kind of device. But now we 
make certain to let him know that we feel a lot more 
comfortable when he walks away from a review than if 
he hasn't been at it. 

In fact, we try vety hard to make sure that if there is 
a survey done of the use of this kind of device on any 
particular project, we ask him to take a look at it. I mean 
it doesn’t have to be a team of people that board a 
project. It can be just one expert. 

Are you worried that the CAIB report paints too broad a 
picture of the problems in the agency? 

Actually, I am less worried about what the CAIB Report 
says than I am with what some might think it says. I do 
worry about that. I was pleased to see that Admiral 
Gehman has said that if he had been asked to do an 
overall evaluation of NASA and the Human Space Right 
Program, there would be a lot more good that he would 
have to say than there would be bad. The fact of the 
matter is: That isn't what he was asked to do. What he 
was asked to do was focus on our problems. 

We’re not talking about abandoning something 
because it’s beyond hope. That isn't the case. We're 
talking about improving something that's worth 
improving. The margins are too slim and the 
consequences are too great for us to recognize that we 
can do better and not do it. We need to improve. That’s 
what we need to be doing all the time. 

What would you like to see as the legacy of your work on 
the “Diaz Report/’ let's say five to ten years from now? 
What would you like to be able to point to and say, “This 
is what came out of it"? 

I don’t have any specific driving issue that I hope that this 
report will help fix. On the other hand, I would be 
satisfied five to ten years from now if I could look at what 
is going on and say, “We made a difference.” • 
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from the editor-in-chief Dr. Alexander Laufer 


Looking Ahead With Anticipation 


Today's fast-changing projects call for managers to he highly responsive to 
the unexpected — those surprises that can alter the course of a well-laid plan 


The "old school” approach was to emphasize control 
as adherence to plan — much like using a thermostat: a 
point is set; then, by measuring the temperature, the heat 
is turned on or off, maintaining the pre-determined 
standard. It's simple and stable. But projects rarely are. In 
today's fast-changing world, a more suitable metaphor 
for project control would be coaching. A coach would 
hardly be effective if he was isolated in the locker room, 
receiving statistics via a monitor — he needs to see the 

o 

game in order to guide his team. 

While it may not be possible to eliminate uncer- 
tainty, you can anticipate many of its surprises before 
they occur, and hence lessen their impact. Project 
managers must review formal reports — as well as "move 
about” during the progress of a project. I call this 
"systematic monitoring,” a two-step process of evalu- 
ating critical planning assumptions and providing timely 
feedback for continuous planning. 

The following 15 rules for systematic monitoring 
are taken from "Ninety-Nine Rules for Managing 'Faster, 
Better, Cheaper' Projects,” which can be accessed in its 
entirety at http://67.92.16.242/nasa/laufer/99rules.htm. 

1 . Identifying a small problem is difficult; correcting it 
is easy. Identifying a big problem is easy; correcting 
it is difficult. 

2. Dynamic environments require monitoring the 
validity and achievement of objectives (effectiveness), 
and the utilization of the means (efficiency). 

3. In unsuccessful projects, there is never enough time to 
do things right, but there's always time to do them over. 

4. Management systems don’t control projects. People 
do, helped by management systems. 

5. Only team members directly responsible for project 
implementation can control projects. 

6. What is yet to come can be controlled. Last week’s 
performance is relevant to the project team only 


when it helps them decide how to do next week’s 
work better. 

7. More paperwork does not ensure more reliable or 
accurate information — and it only seems that more 
measurement and reporting means better control. 

8. Excessive control often "encourages" employees to 
distort data or develop aberrant practices to suppress 
critical information in fear of management reprisal. 
This, in turn, provokes even greater management 
suspicion and scrutiny. 

9. Successful teams know that effective project control 
does not result from reviewing and analyzing 
performance reports, but rather by carrying out 
effective front-end planning. 

10. Managers who stay in one place are forced to make 
complex judgments with incomplete cues. 

1 1 . Master project managers control the project by 
employing formal performance reports and by 
moving about. 

12. Moving about contributes not only to "under- 
standing,” but also to “influencing” project control; 
plus, it allows project leaders a natural, subtle, and 
timely influence on project activities. 

13. When uncertainty is low, control is best imple- 
mented by measuring performance and then by 
taking corrective steps to adjust performance to the 
plan. As project uncertainty increases, control is less 
of a “governor” of execution, and more of a data 
collection function for continuous planning. 

14. In uncertain conditions, "control” should provide 
feedback for planning, and thus its emphasis should 
be on looking ahead with anticipation rather than 
looking back with justification. 

15. When uncertainty is high, the best way to control the 
project is by selecting adaptable and responsive people. • 
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